EXHIBIT B 



MARKUP SPECIFICATION 



15 



16010/0959I/DOCS/1478112 



Method For Perform i ng Response Time Analysis Of Network 

Performance 

Inventors 

Steven J. Schaffer. Lone Tree. CO. USA 
Jacob Weil. Palo Alto. CA. USA 

COPYRIGHT NOTICE 

[0001] A portion of the disclosure of this patent document contains 
material which is subject to copyright protection. The copyright owner has no objection 
to the facsimile reproduction by anyone of the patent document or the patent disclosure 
as it appears in the Patent and Trademark Office patent file or records, but otherwise 
reserves all copyright rights whatso e v e r. a The following notice applies to the software 
and data as described below and in the drawings hereto: Copyright © 2001 , 
Compuware, All Rights Reserved. 

FIELD OF THE INVENTION 

[0002] This The present invention relates to the field of network computing, 
and more particularly, to a method and system for monitoring network, client, and server 
performance. 
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BACKGROUND OF THE INVENTION 

[0003] One wav4e method of monitoring network performance is by 
measuring the processing time on a first node, such as a client, and the processing time 
on a second node, such as a server. I n e arlier vers i ons. In conventional approaches, 
this approach was applied where the client and server were on the same LAN ( local 
area network (LAN) , so that factors such as network delay external to the LAN did not 
need to be considered. 

[0004] To accommodat e mor e r e alistic i mp le m e ntat i ons, n e twork d el ay 
shou l d also b e Realistic implementations involve networks that generally include multiple 
LANS and interconnecting equipment and/or communications links. Thus, there is a 
need for an improved system and method of monitoring network performance whereby 
network delay is considered when monitoring network performance. 
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SUMMARY OF THE INVENTION 

In one aspect of the invention, a method for monitoring network performance is 
disclosed. The method monitors a flow having one or more frames within a thread by 
calculating a node's active time , i nclud i ng . This includes the amount of time each of th e 
frame sframe is processed on a sending node in a network-and ± the amount of time each 
of th e fram e s frame is processed on a receiving node in the network^ and the amount of 
time each of th e fram e s frame is in transit across the network. 
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BRIEF DESCRIPTION OF THE DRAWINGS 

[0005] The present invention is illustrated by way of example, and not by 
way of limitation, in the figures of the accompanying drawings and in which like 
reference numerals refer to similar elements and in which: 

[0006] FIG. 1 illustrates an Application Performance Report in a Chart 

format. 

[0007] FIG. 2 illustrates an Application Performance Report in a Details 

format. 

[0008] FIG. 3 illustrates an example of Request Preparation and Reply 
Preparation processing types. 

[0009] FIG. 4 illustrates one exemplary embodiment. 

[0010] FIG. 5 illustrates an example of a flow. 

[001 1] FIG. 6 illustrates an example of a multi-tier algorithm. 
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DETAILED DESCRIPTION OF THE INVENTION 



[0012] The present invention includes various operations, which will be 
described below.-Th e These operations of th e pr e sent i nvent i on may be performed by 
hardware components or may be embodied in machine-executable instructions, which 
in turn may be used to cause a general-purpose or special-purpose processor or logic 
circuits programmed with the instructions to perform the operations. Alternatively, the 
operations may be performed by a combination of hardware and software. 

[0013] The present invention may be provided as a computer program 
product whiehthat may include a machine-readable medium having stored thereon 
instructions which may be used to program a computer (or other electronic devices) to 
perform a process according to the present invention. The machine-readable medium 
may include, but is not limited to, floppy diskettes, optical disks, CD-ROMs (Compact 
Disc-Read Only Memories), and magneto-optical disks, ROMs (Read Only Memories), 
RAMs (Random Access Memories), EPROMs (Erasable Programmable Read Only 
Memories), EEPROMs (Electromagnetic Erasable Programmable Read Only 
Memories), magnetic or optical cards, flash memory, or other type of media / machine- 
readable medium suitable for storing electronic instructions. Moreover, the present 
invention may also be downloaded as a computer program product, wherein the 
program may be transferred from a remote computer (e.g., a server) to a requesting 
computer (e.g., a client) by way of data signals embodied in a carrier wave or other 
propagation medium via a communication link (e.g., a modem or network connection). 
Accordingly, herein, a carrier wave shall be regarded as comprising a machine-readable 
medium. 
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Introduction 



[0014] Response Time Analysis (hereinafter RTA) first produces 
underlying data4te£4s . This data is then formatted and presented to a user in several 
reports, including the Application Performance Report (Chart and Details), Node 
Processing Time Report, and Flows Report. The RTA a l gorithms and tochn i quos are 
th e und e r l y i ng t e chnology that produc e s i nformation that i s reoorts are presented in the 
GU Uform of a Graphical User Interface jGUI) . 

[0015] The user's first exposure to the response time analysis is in the 
high-level summaries presented in the health report.-T^^os e The summaries giv eenable. 
the user quick to quickly obtain critical information without pour i ng through th e needino to 
process details. Many of tho deta il s Details are-the^ made available in the Node 
Processing Time report and Flows fReport. 

[001 6] This document contains The following sections give a thorough 
description of the algorithms and techniques used in the underlying r e spons e tim e 
ana l vz e r RTA. as well as examples of the GUI . 

Application Performance Report 

Chart 

[0017] FIG. 1 illustrates an Application Performance Report. The four 
summary results shown in the first panel of the application performance report aref 
given in the following paragraphs. 
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Network Busy Time 

[0018] The ^Network bgusy tlime 100 is the total time that one or more 
meaningful frames are in transit across the network. Network Busy Time is computed 
and reported for both network directions (from primary to secondary and vice-versa). 
After the Flow concept has been introduced the Network Busy Time will be revisited to 
describe which frames are meaninaful.-No t Because only a subset of all frames 
generated traverse the networkr-^Ognly frames that are exchanged between the two 
capture points are included in the Network Busy Time. Consequently, Network Busy 
Time is applicable only with a multi-segment merged or adjusted trace. A trace is a 
sequence of frames that have flowed between two or more nodes over the time caoture 
period of a captur e (to be discussed below). Traces can be merged and adjustedrfef 
e xamp le . & The Network Busy Time can be broken down into two parts: insertion time 
and queuing propagation and processing time. 

[0019] Insertion Time (sec):^Efre This is the cumulative time i t took for 
the frames to be inserted into the network. In a merged or adjusted trace, the insertion 
time for each frame is computed as AdjustedBytes * 8 / Bandwidth. The network 
bandwidth utilization is computed for each direction of the network. Only frames that 
are known to have traversed the network are included. The term AdjustedBytes is used 
in the above expression to indicate the bytes that would have occurrod at thp point the 
fram e cross e d traversed the WAN link. The capture environment allows the user to 
specify tfwhether the frame size of fram e s should be adjusted to compensate for the 
different WAN headers. If the user chooses to adjust th e fram e sd oja then 
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AdjustedBytes = Bytes(as captured) - DLCHeader(as captured) + DLCHeader 
(specified in capture environment^ 

[0020] Network Queueing, Propagation & Processing (QPP) Time 
(sec) : The port i on o f This is the time that frames were present in the network that i s 
caused bv au e u ei na due to queuing (in routers), processing and propagation. This 
fs represents the portion of the total transit time that is not counted as insertion time. 
Throughout the description, this term is referred to as QPP time. 

Node Active Time 

[0021] Th e r e is one bar for each nod e Referrina aaain to Fia. 1. in the 
Node Active Time 102, showing th e portion of th e task durat i on for wh i ch th e nod e 
wa sarea 102. there is one bar for each node that shows the active , ei th e r ^processing 
or sending ) duration . Each bar is broken down into the following two components^ 

[0022] Node Processing Time4- For each node, the overall nod e task 
processing time is a m e asur e of th e amount of tim e that th e nod e was proc e ss i ng 
dur i ng task, shown. A task is a user-invoked operation that creates network traffic in th e 
cours e of i ts durinq execution and e nds w i th causes a screen update or other 
acknowledgement on the user's machine. A task, onc e Once invoked, a task executes 
to completion w ithout further user intervention unt il i t has f i n i sh e d proc e ss i ng . 

[0023] For single -threaded applications, this is simply the sum of the 
individual node processing times (described iate rbelow) . If an application can have 
multiple server reouests outstanding to a s e rv e r (such as the typical Web browser), then 
the node is considered processing if it is proc e ss i no handling one or more requests. The 
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Node Processing Time for any node cannot b e gr e at e r than th e durat i on ofg xcjggl the 
task duration , whereas the sum of the Processing Times for all nodes can b e larg e r 
than exceed the task% duration if there are parallel (overlapping) threads. 

[0024] Node Sending Timei- For each node, the overall node sending 
time is th e amount of tim e tha t represents the period during which the node is in th e 
proc e ss of sending data T but is-not otherwise processing. If a node is in the process of 
sending a set of frames, then the node is considered to be in the sending state, but only 
if it is not processing another request at the same time. Sending time is important 
because it could indicate that the node is processing in order to prepare the remaining 
frames, or i t could b e caus e d by oth e r factors that do not i ndicat e that tho nod e 
wa sotherwise not processing. The most likely other factor is that the network is heavily 
utilized and the node cannot send all of its data at onc e , in one transaction. Other 
eause spotential scenarios include an-insufficient TCP window size, the normal slow- 
start nature of TCP, inability of the receiving node to remove the data from the TCP 
buffer fest ouicklv enough, or an inefficient TCP implementation at either the sending or 
receiving node. 

[0025] From th e Appl i cation Porformanco Chart, doub l e c li cks w i l l 
fesutt Referrina aaain to FIG. 1. the following detailed reports are available bv double- 
clicking certain areas as discussed in the following dr il l downs: paraoraphs. 

[0026] On a Node Processing Time portion of a node bar: Brings up the 
Node Processing Detail report filtered / highlighted on the specified node. 
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[0027] On a Node Sending Time portion of a node bar: Brings up the 
Node Sending Detail report filtered / highlighted on messages sent by the specified 
node. 

[0028] On either network ba r 100 : Brings up the Network Utilization and 
Latency graph. 

Details 

[0029] An example of an Application Performance Report — Details is 
shown in FIG. 2. The major sections of the detailed report are described in the following 
sections. 

Overall Summary 

[0030] The purpos e of th e overall summary 200 is to g i v o tho us e r 
m feprovides information on the task duration, any errors that were detected, the capture 
environment, and a v e ry t e rs e summary of the conversations, threads and turns. The 
information in the overall summary can alert the user to errors ± o r th e fact that th e y may 
not hav e captured what thoy intended to captur e (for examp le , i f th o task timo, number 
nf nnnv ei r . nt i onfi nr niimh e r of thr e ads i sn't what th e us e r e xp e cts) to the fact that other 
than the desired information was captured. The values displayed in this section are as 
follows. 

[0031] Th e va l u e s disp l ay e d i n th i s s e ction ar e : 
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100311 [Q632]-Task Time (sec)f Th eThis is the duration of the task . This ± 
and should be equivalent to the task "stopwatch time," of th e task. If i tthis is not the 
case , then portions of the time may be missing or may need to be deleted. 

r0032f {Q033]-Traffic Duration (sec V Tho span of t i mo dur i ng This is the 
duration within which frames exist. The user can click on the label to open the bounce 
diagram, which will show them all of-tfr econstituent frames and tho timo per i od that th e y 
ssaf rtheir durations . 

r00331 r003 4 1 Errors: A Errors A click on the Errors label opens the 
Error Report, which is a graphical summary of the number and types of errors T and 
warnings , and i nformational e rrors detected in the trace. A c li ck on th e Errors l ab el 
op e ns th e Error R e port. 

[0034] {0Q35]-Capture Environment- This-is-a legend , so to sp e ak, for 
indicates the meaning of the arrows that ar e shown in many other places mwithin the 
report. A capture is a process whereby a traffic collector or capture agent li st e ns for 
af>d-collects network frames exchanged between nodes in a distributed application and 
stores thafe data for off-line analysis. The legend keys are taken from the Capture 
Environment as_specified by athe user. The primary capture location is indicated on the 
left and the secondary location is on the right. 

r00351 TOQ361-Convj - indicates Conversations, both th e tota l for the task 
and the total , and those that afe occur between oneg node on the primary location and 
another node in the secondary location )= §§ indicated by the "<-->" label. Hereafter, the 
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phrase "conversations that traverse the network" means conversations for which one 
node is in the primary location and the other is in the secondary location. 

r00361 fQ0374-Threads4-4fr e This shows both the total number of threads 
in the task (Tota l ) and as well as in the conversations that traverse the network between 
the primary and secondary capture points. A thread is a sequence of frames 
exchanged between two nodes that constitutes a single application or protocol action. 
For example, the retrieval of a graphic from a WWW (World Wide Web) server is a 
thread. A thr e ad wi ll a l ways b e b e tw ee n a pa i r of nod e s. 

r00371 fflQ38lTurnsi--The This is the number of turns in the task, and in 
the conversations that traverse the network between the primary and secondary capture 
points. <--> Turns specifies the sum of the turns for threads that have correspondina to 
one node in the primary location and th eanother other node in the secondary location. 

f00381 {QQ39]-Bytes/TurrH Ifr eThis is the average number of bytes \n 
eaefroer turn, both as a total for the task and for the conversations that traverse the 
network. 

r00391 {OMOJ-Frames/TurnT-AAftwte (not shown , th i s character i st i c can 
a l so b e sp e c i f ie d. I t d e f i n e s ) This is the average number of frames in each turn, both as 
a total for the task and for the conversations that traverse the network. 

Traffic 

r00401 r00 4 11 Tho traffic Traffic section 202 provides the user with a« 
ov e ral ls summary of several traffic measures, for the entire task (the-Total row), over 
the network (the-<--> row ), and i n each direction across tho network. As us e d horoin, 
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"over tho network" wil l moan , i.e.. in both directions between the primary and secondary 
capture points ), and in each direction across the network . Columns in this section 
i nc l ud e : are discussed in the following paragraphs. 

[0041] fOQ421-Bvtes4— Sum This is the sum o f the bytes for all frames in 
each classification. For the network classifications, the byte counts for each frame will 
be adjusted for the DLC header size if the user has chosen to p e rform th i s 
adjustm e nt do so in the capture environment. 

r00421 {0©43j-For <-->, -> and <r Bytes, the value is the number of bytes 
that crossed the point of contention in the network as specified for the task in the 
Capture Environment for th e task. , If the user did not choose to adjust frames for DLC 
header in the capture environment, then Network Bytes = Bytes for each frame. If the 
user did so choose to adjust fram e s for DLC h e ad e r i n th e captur e e nv i ronm e nt , then 
Network Bytes = Bytes - DLC Header(as captured) + DLCHeaderbytes (specified in the 
capture environment), 

K)0431 [00 44 ] % of <--> Bytes : App l icabl e on l y to th e two dir e ct i ons of th e 
n e twork, th i s This column shows whatthe percentage of tfr e<--> bytes that traversed 
the network ar e attr i but e d to rn each direction. The two values will add to 100% (subject T 
of cours e , to rounding i n th e d i sp l ay ). 

[0044] fO045}-Frame$T Th eThis is the total number of frames in the task 
(top row), and the number of frames that should have crossed the network, whether 
they were contained in both captures or not. If they weref rt not , such will be reported in 
the two Frames Missing co l umns at entries to the right of this section. A frame is a 
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collection of bits comprising data and control information (overhead) that is transmitted 
between nodes in a network. 

[00451 f0048}-Avg Frame^Ph e This is the average frame size, in bytesr 
Ava Frame ~. i.e.. Bytes / Frames. 

r00461 [0Q47]-Captured Load (kbps and %) : The captur e d l oad j tns is 
the average rate, in kbps and as a ^ percentage of the total bandwidth, of the frames 
that traversed the network in each direction. The adjusted bytes (r e f e r to th e 
d i scuss i on , as discussed above} ± are used. 

1*00471 {0G48]-Frames Missing at Sources The This is the number of 
additional frames from the sending (source) node that should have been in the trace 
from th e captur e point wh e r e th e s e nd i ng (sourc e ) nod e was p l ac e d. Fram e s m i ss i ng at 
th e sourc e ar e usua ll y an i ndicat i on that th e y shou l d hav e b ee n captur e d but w e r e not. 
^This can be caused by the capture beginning too late or ending too early, or by the 
inability of the capture device to capture all of the frames. 

r00481 [0049]-Frames Missing at Destination^-Th e (not shown) This is 
the number of additional frames that should have been s ee n in the trace from the 
captur e point wh e r e th e receiving (destination) node was plac e d. Fram e s m i ss i ng at th e 
d e st i nat i on . Such frames could be have been lost m-the due to network du e to 
congestion or a-failure of a network component, or th e y cou l d b e m i ssing for the sam e 
r e asons that fram e s m i ssing at th e sourc e can b e miss i ng reasons discussed in the 
preceding paragraph . 



14 



16010/01000/DOCS/1480370 



r00491 {OOSOJ-There can be other situations wherein not all of the frames 
that should have traversed the network were actually captured , th e r e by r e su l ting i n 
m i ssing frames. & For instanoo example , one of the captures may have started before or 
ended after the other and may contain frames that traversed the network. However, 
since those frames are not represented in the other capture, it is not known if they 
actually traversed the network. Such frames will be flagged with an e rror of Lost Frame 
or Dropped Frame, r e spoct i voly, depending on whether i t was thev were captured only 
at fethe source s e gm e nt or destination segment , respectively . 

rOOSOl [0051] If it is assumed that missing frames really did traverse the 
network, then their bytes / frames / threads / conversations are included in the <--> 
metrics. There is no way to know whether a frame that is missing at the destination 
actually consumed bandwidth at the network contention point before being dropped. 
Thus, the worst case is assumed — . i.e.. that i t d i d consum e network bandwidth was 
consumed , and the_ missing frames are-alse included in the <--> metrics. 

Network Busy Time 

r00511 r00521 Tho network busy t i m e The Network Busy Time section 204 
helps the user determine how bys vactive the network was during the task ± and how 
thatg busy time breaks down into insertion time and QPP time. 

F00521 r00531 Th e n e twork busy t i m e The Network Busy Time section 204 
is presented for merged tasks and single-trace adjusted tasks. There are two rows for 
the network metrics, one for the primary to the secondary location (->), and the second 
from the secondary to the primary location (<-). The columns in this section co rrespond 
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exactly to the portions of the network bars 100 in the Application Performance Report 
chart of FIG. 1. 

{0054] Th e co l umns i n th i s s e ct i on corr e spond e xact l y to th e port i ons of 

th e n e twork b a rs i n th e App li cat i on P e rformanc e R e port graph. 

r00531 {00S5]-lnsertion Time (sec and % of Task Time^ -4fre This 
information represents the cumulative time that it took to insert the captured frames into 
the network at the point of lowest bandwidth specified by the user. Th e i ns e rtion t i m e i s 
bas e d on th e n e twork bvt e s of e ach fram e should Should the user decide to adjust for 
DLC headers of the network by the captured bvtes . the insertion time is bas ed on the 
network bytes of each frame . The bandwidth ^ utilization in kbps is^ - determined as 
{Bytes that traversed the network in the specified direction * 8} / (duration of the task in 
seconds * 1000). The bandwidth ^ utilization in % is (the bandwidth ^utilization in 
kbps / capacity of the link in kbps) ± expressed as a percentage. The capacity of the link 
is specified by the user in the capture environment. 

r00541 {OOSSf QPP Time (sec and % ): Qu e u ei na of Task Time) This is the 
Queuing . Processing and Propagation time. 

r00551 {0057]-Total (sec and % of Task Time) : The total time that one or 
more meaningful frames was traversing the network. Meaning frames include all data 
frames and TCP acknowledgements that are within the data portion of a message. 
Meaningful frames do not include TCP acknowledgements that are sent after the last 
data frame in a message is sent. 
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Network Frame Transit Statistics 

[0058] Th e n e twork frame trans i t stat i stics s e ction 206 compr i s e s 2 rows, 

on e for oach d i rection of the network as d e scr i bod abovo. 

r0056] fflQSSl -The network frame transit statistics section 206 comprises 2 
rows, one for each network direction as described above. This section includes only 
meaningful frames. As such, the statistics do not include TCP acknowledgements that 
occu r are sent after the last data frame in a message is sent . 

f00571 {0060}-Transit Time (sec)f th e firs t This column will conta i n reflect 
the graphical depiction of the min. avg. minimum, average and ma xmaximum frame 
transit time. The transit time of each frame is the difference between its Time Sent and 
Time Received. 

r00581 fOOS4f Transit Time Min (sec)f Th eThis is the transit time of the 
frame that has the sma lle st lowest transit time. 

[0059] {00£2}-Transit Time Avg (sec) : Th e This is the average (mean) 
transit time for the meaningful frames. 

r00601 f00€3]-Transit Time Max (sec):^Ffr e This is the transit time of the 
frame that has the largest transit time. 

r00611 {0064]-Transit Time Frame Count The This is the number of 
frames included in the transit time statistics . Eou i va l ont . and is egual to the number of 
meaningful frames that were captured at both sides (or adjusted). Note that this 
number is equal to or less than the number of frames that traversed the network in the 
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specified direction. It does not include TCP acknowledgements after a message or 
frames that are missing at the source or destination. 

r00621 f006S}-Latency Statistics (min, avg, max ): \Nh \ \e ± not shown T } 
These are statistics on the latency of meaningful frames that traverse the network-may 
b e shown. & As described b e for e above . meaningful frames are data frames and the TCP 
acknowledgements that occur during the data transfer portion of a flow. 

r0063] {QQ6€}-0verlap Avg ( Fram e s): Frame) Th eThis is the average 
number of frames that are in transit when there is at least one frame in transit. It is a 
measure of the application's ability to send more than one frame at a time ± and the 
network conditions requiring the application to do so. Put anoth e r wav In other words , it 
is the average number of frames sent by the application when the application has sent 
frames. Higher values mean the application is less susceptible to network latency and 
bandwidth. 

r00641 {OOSTfOverlap Max ( Fram e s): Frame) Th eThis is the largest 
number of frames that are in transit in the network at any given time. 

Node Active Time 

r00651 f00€8]-This is a tabulaftion4efmat 208 of the node bars (processing 
and s e nd i na 102 (Node Processing And Sending times) that were described earlier in 
the Application Performance Report Chart r of FIG. 1. 
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Node Processing Statistics 

F00661 {0068}-Statistics Qfi 210 regard the node processing periods, as 
discussed in the following paragraphs . 

r00671 fOOTOfProcessing Time (sec)T A This reflects a graphical 
depiction of the min. ava minimum. average and ma xmaximum node processing time 
period. 

[00681 {0©74J-Processing Min (sec)r Th eThis is the shortest node 
processing period. 

[0069] {0072]-Processing Avg (sed : The This is the average node 
processing period. 

r00701 {0©73}-Processing Max (sec)f-4fre This is the longest node 
processing period. 

r0071l {0Q74]-Processing PeriodSr The This is the number of processing 
periods , and is important as it tells the user if there afeis a large or small number of 
node processing periods. 

r00721 {0075}-Overlap AvgT Th eThis is the average number of 
processing periods that occur simultaneously at the node during the times that the node 
is in at least one processing period. A value of 1 .0 means that the nodie never 
processed more than one request at a time. This value cannot be smaller than 1 .0. 

[00731 fO07€]-Overlap Maxi Th eThis is the largest number of processing 
periods occurring at any given instant. 

16010/01000 /DOCS/1480370 
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Node Processing Detail Report 

r00741 ' [0077] In addition to the overall summary results presented in the 
Application Performance Report, the RTA also identifies and reports several sets of 
details. One of these is the node processing detail (not shown) . 

r00751 {0©78J-Each node processing time is one component in the Overall 
Node Processing Time. The U IGUI allows on ethe operator to see the Individual Node 
Processing Times for all nodes or for one node at a time. Note that since individual 
node processing times can overlap, the sum of the individual node processing times can 
be greater than the Overall Node Processing Time for a ftode roiven node. The attributes 
of each node processing time, as given in the columns in the Node Processing Detail 
Report are listed or described in the following sections. 

[0079] Th o attributes of e ach nodo processing time (aka co l umns i n th e 

Nod e Proc e ssing D e tail R e port) ar e : 

r00761 [0080]-Node Name, 

r00771 f00S4f Node Address, 

r00781 [00S2]-ErrorsT Th eThis is the number of errors associated with 
either the start or the end frame. The user can dr ill i nto to click on the error report to see 
the individual errors. 

f00791 fQQ&3]-Duration (eort o d desc e nding bv d e fau l t). Th e This is the 
time span of the processing time, in seconds. 

{0084] Proc e ss i ng Type. Ono of th e li st sp e c i f ie d b el ow 
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r00801 {0085]-Start Time? Th e This is the time at which the node began 
processing 

[00811 f0086]-Start Framer-Th e This is the number of the frame 
numb e r captured at the beginning of the processing time. The user can dri ll down to digk 
on this parameter to view the bounce or packet trace wh i ch wi l l tak e th e m to as of the 
start frame. 

[00821 fOOSTJ-End Timer Tfre This is the time at which the node stopped 
processing. 

r00831 {QQ88]-End Frame . Tho fram e This is the number tfra^is of the 
frame captured at the end of the processing time. The user can dril l down to click on this 
parameter to view the bounce or packet trace wh i ch wi l l take th e m to §| the end of the 
frame. 

r00841 {0088}-Start Frame Description The This is the description 
(decoded) of the start frame. 

[00851 {0©90]-End Frame Description? The This is the description 
(decoded) of the end frame. 

r00861 roQ044 -Node Process ing T ype This is one of the types specified 
in the sections below. For most of th e node processing types, there are corresponding 
processing types for client and server. For o xamp l o, C l i e nt Procossing and S e rv e r 
Procoss i ng. Th e y bas i ca ll y hav e tho samo m e an i ng, but tho "C lie nt" on eJ^Ugnf is 
assigned when the node is the client in a thread wh o r o as th o "S e rver" ono i s assign e d 
wh e n th e nod e is th e s e rv e r in th e thr e ad. . and vice versa. Each node processing type 
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has an internal code numb e r that is li st e d i n par e nth e s e s. Th i s cod e numb e r n e v e r 
app e ars that does not appear in the GUI. The node processing types and their 
meanings are f given in the following sections. 

f00871 {0082]-Client Before Thread 3QQ: Th e This is shown in FIG. 3 at 
300. and represents the time period prior to sending of the first data frame i n th e thr e ad 
wh e n that f i rst data fram e i s s e nt by the client. The proc e ss i ng tim e period extends back 
to the previous data frame that was received by the node ± orjQ the beginning of the task 
if there i sn't on e is no such frame . 

r00881 {0093}-Client Processing : W i thin This the period within a thread 7 
wfrefi from receipt of a data frame bv the client node to the time that node sends eut-a 
subsequent request , th e t i m e b e for e that r e qu e st is cons i d e r e d to b e a cli e nt proc e ss i ng 
t i m e . Th e t i m e e xt e nds back to th e pr e vious data fram e that was r e c ei v e d by th e c l i e nt. 
Not e that that . The data frame can be on the same thread o r i t can b e on another 
thread. 

r00891 fO0S4}- After last frame 308t Th eThis is the time period from the 
last data frame to the end of the task , and is always assigned to the client node for thegt 
task. You can r e ass i gn th e The client node can be reassigned in the conversation map. 
Th i s proc e ssing typ e w ill a l ways e nd at th e t i m e that i s th e e nd of th e task. 

r00901 {00d5}-Server Before Threads This is def i ned in the same way 
as similar to Client Before Thread, but occurs i f arises when the first data frame in the 
thread is sent by the server of the thread. Normally on e wou l d not oxpoct tho server of 
th e thr e ad to the server does not send the first data frame ± (since the client normally 
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initiates activity by sending a reouestVbat . However, if the capture starts in the middle of 
a thread, or if the client and server are assigned incorrectly then you may g e t th i s 
proc e ssing typ e . Not e that th e Thr e ad Ana l ys i s w i ndow compr i s e s a command to swap 
th e c l i e nt and s e rv e r of a thr e ad i f th e v ar e i d e nt i f i ed incorr e ct l y. , then this processing 
type results. 

[0091] Note that the Thread Analysis window comprises a command to 
swap the client and server of a thread if thev are identified incorrectly. 

f00921 {GOSSJ-Server Processing 304 : Within a thr e ad, this JThis is the 
time period within a thread from th e po i nt that receipt of the last frame in a request is 
r e c e iv e d by the server to the time that the first response frame is returned by the server. 
During this time ± the server is assumed to be processing the request and cons e qu e nt l y 
this tim e i s i d e nt i fi e d as a s e rv e r proc e ss i ng t i m e . ± Note that with multi-tier applications 
(discussed below) there are cases where an upper-tier request may interrupt a server 
processing time. Mult i- t ie r i s d e scr i b e d l at e r. 

r00931 [0097] Request Preparation 302^4fi This processing type arises 
in multi-tierT-wheft applications. It is the period from receipt of a reouest bv a mid-level 
server proc e ss e s aft e r r e c ei v i ng a r e qu e st (from a lower tier) until rt the mid-level server 
begins sending a subsequent request to another server. F I G. 3 shows th i s proc e ss i ng 
typ e at th e App S e rv e r b e tw ee n fram e s 1 and 3. 

[0094] [0098] Reply Preparation 306^4 ^ This processing type also 
arises in multi-tien-wfrefi applications. It is the period from receipt of a reply bv a mid- 
level server proc e ss e s aft e r r e ce i ving a r e p l y (from another serve r until i t b e g i ns 
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s e nd i ng i ts ) to initiation of a reply to fethe requesting node. F I G. 3 shows th i s 
proc e ss i ng typ e at th e App S e rv e r b e tw ee n fram e s 5 and 7. 

Flows Report 

[0095] {QQ99]-A flow is a set of data frames that is sent from one node to 
anothe r. Sp e c i f i ca l ly, a f l ow ± comprises only frames in a single thread, and spans a 
time period wh e r e th e r e ar e durina which no data frames travelm§ in the opposite 
direction. A flow aiso-includes the TCP acknowledgements that are sent in the opposite 
direction dur i ng th e f l ow and before the d i r e ct i on of data transmission direction 
reverses. 

r00961 {04G0]-Meaningful frames w e r e^ discussed e arl ie r. Al l above. 
comprise all data frames T and TCP acknowledgements within a data flow-afe 
m e an i ngfu l fram e s. ^ TCP acknowledgements that occur after the last data frame in a 
flow are not meaningful frames for the purpose of network busy time computation. 

r00971 [0101] In the flows report, each flow has th e fo ll owina includes a 
number of attributes ^, arranged in columns ^, as discussed in the following sections. 

ID0981 {04031-ErrorsT- A The flows report provides a graphical depiction 
of th e numb e r o f relevant errors and warnings ± as i s don e i n with other reports. I nc l ud e s 
aA link to the error report wh e r e th e e rrors b e long i ng to fram e s in th e f l ow wou l d b e 
shown, is provided. Since a flow comprises one or more frames, the errors ident i f ie d by 
^associated to with any frame in the flow should be included in this summary. 

[00991 f04O3J-Sending Node 4 This is the name and address ). Th e of the 
node that sendst the data frames in the flow. This node will atee-receive TCP 
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acknowledgements from the corresponding receiving node. 

[0100] f0434]-Receiving Node- f This is the name and address ). Th e ^ of 
the node that receivesd the data frames in the flow. This node will alse-send TCP 
acknowledgements to the corresponding sending node. 

[0101] {046§]-Data Duration (s e conds): Th e t i mo This is the period in 
seconds from whe ftthe time the sending node sent the first frame in the flow to the time 
that the receiving node received the last data frame in the flow. This is related to other 
fields as fo ll ows: bv the relationship Data Duration = (End Data Time - Start Time) 

[0102] f0+06]-Avg Data Rate (b i ts/s e cV Th e This is the average data 
rate in bits/sec during the flow. This i sinformation mav be important to the user. 
because flows with low data rate may be worthy of furth e r demand investigation . For 
example, the user mav need to determine why the data is not being transferred more 
quickly, particularly if the flow is also longer than most other flows. Computed This is 
computed as (Data Payload Bytes * 8) / (End Data Time — Start Time^ 

[0103] r01071 Bvtes . Th e This is the total number of bytes in all of the 
frames in the flow. 

[0104] f0448]-Data Payload Bytesv The This is the sum of the payload 
bytes fofin all of-the-frames in the flow. 

[0105] fQ4Q91-Frames . Numb e r This is the number of frames in the flow. 

[0106] {Q44Q]-Data Frames . Numbe r This is the number of data frames 
in the flow. 
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[0107] 

frame in the flow. 



[0111] First Framer Tfre This is the sequence number of the first 



[0108] [0112] Last Data FrameT Tfr eThis is the sequence number of the 
last data frame in the flow. 

[0109] {0443}-Last FrameT The This is the sequence number of the last 
frame, either data or acknowledgement. If there are TCP acknowledgement frames 
after the last data frame, then this will differ from the Last Data Frame. 

[0110] {0444}-Start TimeT The This is the time that the first data frame was 

sent. 

[0111] [0115] End Data Time 7 Th eThis is the time that the last data frame 
was received. 

[0112] [0116] End Time^ Th eThis is the time that the last frame (data or 
acknowledgement) was received. Note that this is normally not important because 
trailing TCP acknowledgements do not have an impact on the response time. 

[0113] [01 17] Oth e r columns that may b e inc l ud e d ar e : 

[0114] [0448]-Data Directiom-Eithe f This reflects primary-to-secondary 
direction or vice versa . B es L as indicated with arrows (-> and <-) arrows . For flows that 
are within a capture location, shou l d road the caption "within <capture Point>" appears T 
where <capture Point> indicates the location of interest. 



[0115] {Q449]-Network Busy Time (seconds). Th o This is the total time 
in seconds that one or more frames was in transit during the flow. 

1 60 1 0/0 1 000/DOCS/l 4801 70 



[0116] RTA Algorithm Details 
[01 1 7] Overall Approach 

[0118] [01 20] The RTA functions first at the thread level. Each thread is 
assumed to be a single-threaded sequence of request / response exchanges between 
the client of th e thr e ad and foe-server of the thread. A It is the responsibility of the 
protocol decoder to ensure this requirement. A thread is broken down into 5 time 
periods that f i t i nto , described in the following 5 catoaor i os: sections. 

[0119] [0121] Client Processing Timer 

[0120] [0122] Client Sending (Flow j§J)eing sent from client to server^ 

[0121] {0423]-Server Processing T i m e . 

[0122] f0454]-Server Sending (Flow j^being sent from server to client) 

[0123] {&42§}-Processing interrupted by another thread 4 This period 
only occurs in the case of multi-tier or overlapping requests at the client) 

[0124] Exemplary Embodiment - Single Thread 

[0125] f0426/-RTA concepts can b eare illustrated maccordina to one 
e x e mp l ary embodiment as shown in FIG. 4. FIG. 4 shows js a bounce diagram for a 
typical client / server or Web application. -( The application could be anyth i ng f e.g., a 
2-tier SQL application, a web browser te-aZ web server, o r e v e n an application us i ng 
abased on ad hoc protocols.) 

[01 26] [0127] Assume that all of th e s e frames afe4B shown exist within a 
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single thread. In this example ± the client sends a 2-frame request to the server, the 
server processes fe rover a k toeriod . and then the server sends a 3-frame reply back to 
the client. The diagram shows the data frames that would be exchanged^ as well as 
exemplary TCP acknowledgements that w ill bo ooon if the application uses TCP/IP.-( 
Note that TCP is a very dynamic protocol and therefore may not send a TCP 
acknowledgement for every frame.-S e Accordingly, the diagram feelow-i sillustrates only 
one of th e many that cou l d hav e occurrod.l manv possible variations. 

[0127] Node Processing and Sending 

[01 28] [0128] The Application Performance Report — Chart of FIG. 1 
would show that-the processing time for the client wasaj the sum of the two processing 
times identified in th e f i gur e — tn eFIG. 4. i.e.. one at the beginning and the-one at the 
end. 

[01 29] [0129] The processing time for the server is just the single 
processing time i n th e m i ddl e of th e trac e . 

[01 30] r01301Tho 304. and the sending time for both nodes is i nd i oatod i n 
the f i ouro. as indicated in the FIG. 4. 

[0131] Flows 

[01 32] [0131] In this example there are two flows. The first flow is-sent 
from the client to the server and comprises frames 1 through 4. The last data frame in 
thejs flow is frame 3. The overall flow duration and flow data duration of tho f i rst flow 
tsgm annotated in FIG. 5. Because f£rame 4 is a TCP acknowledgement that is sent 
after the last data frame tin the flow (Frame 3) is sen t i n th e f l ow , it is not considered a 



meaningful frame-af^/QM^ the network is not considered busy for the time that frame 
4 is in transit. 

[0133] [0132] A sim i lar SJmilaj; analysis could b e mado fo r applies to the 
second flow in this example. The second flow is sent from the server to the client, and 
comprises frames 5 through 10. The data duration is-fro mfor this flow spans the time 
frame 5 is sent to the time frame 8 is received. 

[0134] Network Frame in Transit and Latency Statistics 

[0135] {0433]-Again r e f e r e ncing referring to FIG. 4, the times when a frame 
is in transit can be seen.-T-h e In general, the TCP acknowledgements that are returned 
after a-f4ewdaj§ is completely received have no impaction the overall response time^-; 
T-iherefore, they are omitted from the network Frame in Transit measure and Latency 
statistics .-to Accordingly, in this example frames 4 and 10 do not impact the user- 
perceived application response time ± and thus thev are not included in the network 
latency measures. 

[0136] f0434]-A high network -frame -in -transit time can be an indication 
that the combination of network latency and the application's sequential request / 
response behavior is affecting the response time. I f you soo high network busy 
time , you shou l d a l oo l ook at tho n e twork ut ili zat i on to s ee i f th e oauo e of the h i gh buoy 
time-i s mav be caused bv insufficient network bandwidth. This can bo oasilv dono This 
mav be investigated bv consulting the network utilization information in the Performance 
Report — Chart s i nc e th e . This chart breaks down a network frame in transit i s brokon 
dewfHnto components caused by bandwidth and latency. If the bandwidth portion of 
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tfre-ka fcomp onent dominates, then tbe-lack of bandwidth is causing the network to be 
busy. 

[0137] Exemplary Embodiment - Multi-Thread 
[0138] Node Processing and Sending Time 

[0139] {M3SJ-Node processing time analysis becomes more complicated 
when the application is multi-threaded. In the example above, the sum of the node 
processing times equals the node active times. When th e r e ar e over l app i ng node 
processing times overlap at a node, only one e fsuch tbjmem is counted-ar*4; 
consequently^ the sum of the individual node processing times can be greater than the 
calculated overall node processing time. 

[0140] [0136] The user is shown results for both node processing and 
sending times. Nod e proc e ss i ng i s wh e n th e nod e is d e f i n i t e ly proc e ss i ng. Nod e 
s e nd i ng tim e s m e an that th e nod e m i ght b e proc e ss i ng and cons e qu e nt l y this tim e 
might contr i bute to th e tota l r e spons e t i m e . S e nding t i mes cou l d bo caus e d by oth e r 
Node processing time unambiguously reflects periods during which the node is 
processing reguests (as a server) or processing a reply prior to sending the next 
reguest (as a client). Conversely, node sending time reflects not only node processing, 
but potentially other activity as well. It is difficult to determine what contributed to the 
node sending time without examining the individual flows sent. For example, node 
sending times could result from factors such as the receiving node's inability to process 
incoming data fas touicklv enough, insufficient bandwidth in the network, the sending 
node's inability to make all of the data available quickly enough, QLa TCP window size 
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that is too small. One can dri ll down from th e nod e s e nd i ng Consequent^ node 
sending time might contribute to the total response time. For example, in cases where 
the network is heavily utilized or has high latency, a high node sending time can be 
caused bv limitations of the network. To explore this, a user can link from the node- 
sendino- time bar to view the flows sent by that node. From thoro, tho us e r shou l d l ook 
at tho f l ows and The user could thereby attempt to identify tfwhether the time laose 
between frames sent by the node was r o a ll y represented actual processing time or not . 
Often this determination will require some knowledge of the application. I n cas e s wh e r e 
th e n e twork is heav il y ut il iz e d or has high l atency, a high nod e s e nd i ng timo can bo 
caus e d by th e n e twork. 

[0141] [01 37] Nod e Proc e ssing T i m e can t ell you how much of th e tim e the 
nod e was proc e ss i ng r e qu e sts (as a s e rv e r) or proc e ss i ng a r e p l y prior to s e nding th e 
n e xt r e qu e st (as a c l i e nt). Th e aggr e gat e s e nd i ng t i m e i s i mportant b e caus e it can t el l 
you how much of th e tim e th e nod e was try i ng to s e nd data to oth e r nod e s. I t is d i ff i cu l t 
to draw abso l ut e conc l us i ons about what caus e d th e s e nd i ng tim e w i thout l ooking at th e 
indiv i dua l f l ows that th e nod e s e nt. 

[0142] Node Processing Times 

[0143] [0138] The Node Processing Detail report (not shown) shows the 
ind i vidua l processing times that were detected for each node. The report is s ort e d 
i nitia l ly i n arranoed in order of descending duration so that vou can o asilv s oo . with the 
largest i ndividual processing times at the top. Nod e proc e ssing t i mos occur at 
Processing time at a client nodes node begins iust prior to th e nodo sending-out the first 
request in a thread, and thef ^ends within a thread prior to each succeeding reguest that 
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the node sends. Processing t i m e s occur at corvors from th e time at a server node 
begins when the server receives a r e sponse unt il th e t i me reauest and ends when thate 
i t server begins sending a reply. 

[0144] [0139] For further understanding of node processing times, a Node 
Processing Detail report can be opened on a trace. The window can then be split, and 
the packet trace placed at the bottom. For each node processing time that is selected, 
there will be two frames surrounding the processing time. For client processing times, 
there will be a prior reply (or the beginning of the trace) and the request that the client 
sends at the end of its processing time. For server processing times, there will be the 
request (actually the last frame in the request if it is a multi-frame request) and the 
response (actually the first frame in the response if it is a multi-frame response). 

[0145] Flows 

[0146] [01 4 0] A s discussed previously, there can be many causes for a 
high node sending time, and the cause of this can be difficult to determine. 

[0147] Overlapping Threads 

[0148] [01 4 1] A ny time two or more threads overlap, more than one node 
can be processing or sending at a time.-Q f Alternately , a single node could be 
processing or sending on more than one thread at the same time. These processing 
and sending times are aggregated by concluding that 

[0149] [01 4 2]Aj | node is processing if it is processing on one or more 
threads, 
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[0150] r01 4 31A or that a node is sending if it is sending on one or more 
threads and is not processing. 

[0151] Exemplary Embodiment - Multi-Tier 

[01 52] (01441 F I G. 6 mav bo us e d to d e sor i b e FIG. 6 describes the 
handling of multi-tier . Th e mult i ti e r a l gor i thm works as fo ll ows: 

[01 53] r01 4 51At oach point i n applications, as follows. At each time that a 
data frame enters a node, the time, frame seq# and its thread is recorded in member 
variables of the CNode class. 

[0154] [01 4 6] When a client of a node sends out the first frame in a 
request, there will be a processing time. To determine its type, it is determined 
tfwhether the most recent data frame that arrived at the node was a request frame from 
another client. If it was, then ^M I SSING TEXT>. the type is 'Request Preparation. 1 
otherwise, the ty pe is 'Client Before Thread. 1 

[0155] Conclusion 

[01 56] [01 4 7] Thus, an oxomp l ary A method and system for performing 
response time analysis of network performance have been described. Although the 
present invention has been described with reference to specific exemplary 
embodiments, it will be evident that various modifications and changes may be made to 
these embodiments without departing from the broad e r spirit and scope of the invention. 
Accordingly, the above description and drawings are to be regarded in an illustrative 
rather than a restrictive sense. 
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WHAT IS CLAIMED IS: 

1 . A method to measure an application's performance in a network, comprising 
within a thread, monitoring a flow having one or more frames by calculating: 

an amount of time each of the frames is processed on a sending node in a 
network; 

an amount of time each of the frames is processed on a receiving node in the 
network; and 

an amount of time each of the frames is in transit across the network. 

2. A method to analyze network performance resulting from a task, comprising: 

displaying a first time representing a time that one or more meaningful frames 
are in a network traveling in a first direction; 

displaying a second time representing a time that one or more meaningful frames 
are in the network traveling in a second direction; 

displaying a third set of times representing times that each of one or more nodes 
in the network is active. 

3. The method of claim 2, wherein the first and second times, and the third set of 
times are displayed in a chart, and: 
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each of the first and second times is represented by a bar that shows at least one 
of: 



a cumulative time that it took for the one or more meaningful frames to be 
inserted into the network; 

the portion of time that the one or more meaningful frames were in the 
network as a result of queueing in routers, processing, and 
propagation (QPP). 

the third set of times for a given node is represented by a bar that shows at least 
one of: 

a total amount of time that the given node was processing during the task; 
and 

a total amount of time that the given node was sending during the task, but 
not processing. 

4. The method of claim 3, wherein the insertion time for each frame is computed as 
AdjustedBytes * 8/Bandwidth, AdjustedBytes being used to indicate the bytes 
that would have occurred at the point the frame crossed a WAN (Wide Area 
Network) link in the network. 

5. The method of claim 2, wherein the first and second times, and the third set of 
times are displayed in a detailed report. 
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6. The method of claim 5, wherein the detailed report comprises one or more of: 
an overall summary comprising the duration of the task; 

a traffic section comprising byte and frame information; 

a network busy time section comprising information about how busy the network 
was during the task, and how the busy time breaks down into insertion time 
and QPP time; 

network frame transit statistics section comprising various transit times for each 
frame; 

a node active time section comprising information about the processing and 
sending times for each node in the network; and 

a node processing statistics section comprising statistics on the node processing 
periods. 

7. A method to monitor network performance resulting from a task, comprising 
displaying a processing time corresponding to a first node in the network, each 
processing time having one or more attributes, including a processing type. 

8. The method of claim 7, wherein the processing type comprises any one of: a 
time period prior to a first data frame in a thread sent by a client; 

a time period prior to a subsequent request within a thread is sent by the client; 
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a time period from a last data frame to the end of the task; 

a time period prior to a first data frame in a thread sent by a server; 

a time period from the point that the last frame within a thread in a request is 

received by the server to the time that a first response frame is returned by 
the server; 

a time period that a first server processes after receiving a request from a lower 
tier until the first server begins sending a subsequent request to a second 
server; 

a time period that a first server processes after receiving a reply from a second 
server until the second server begins sending its reply to a third server, the 
third server being a requesting node. 

9. The method of claim 7, additionally comprising displaying one or more 
processing times, each processing time corresponding to a node in the network 
that is not the first node. 

10. The method of claim 9, wherein each processing time additionally has at least 
one of the following attributes: 

the number of errors associated with one of a start frame and an end frame; 
a time span of the processing time; 
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a time at which the node corresponding to the processing time began processing; 

a time at which the node corresponding to the processing time stopped 
processing; 

a start frame representing a frame number at the beginning of the processing 
time; 

a description of the start frame; 

an end frame representing a frame number at the end of the processing time; 
and 

a description of the end frame. 

11. A method to analyze network performance, comprising generating a flows report 
to monitor a given flow, the given flow having one or more frames that are sent 
from a sending node to a receiving node, and the flows report having one or 
more attributes including: 

an errors attribute depicting the number of errors belonging to the one or more 
frames; 

a sending node attribute indicating the sending node; 
a receiving node attribute indicating the receiving node; 
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a data duration attribute indicating a time period from when the sending node 

sent a first frame in the flow to the time that the receiving node received the 
last frame having data in the flow; 

an average data rate attribute indicating an average data rate for the flow; 

a bytes attribute indicating a total number of bytes in the frames in the flow; 

a data payload bytes attribute indicating a sum of the payload bytes for the 
frames in the flow; 

a frames attribute indicating a number of frames in the flow; 

a data frames attribute indicating a number of frames having data in the flow; 

a first frame attribute indicating a sequence number of the first frame in the flow; 

a last data frame attribute indicating a sequence number of the last frame having 
data in the flow; 

a last frame attribute indicating the sequence number of the last frame, having 
one of data and acknowledgement; 

a start time attribute indicating a time that the first frame having data was sent; 

an end data time attribute indicating a time that the last frame having data was 
received; 
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an end time attribute indicating a time that the last frame, having one of data and 
acknowledgement, was received; 

a data direction attribute indicating a direction in which the flow was traveling; 
and 

a network busy time attribute indicating a total time that the one or more frames 
was in transit during the flow. 
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ABSTRACT OF THE INVENTION 



A system and method and apparatus are described for analyzing the performance of a 
network while processing an application. The method involves measuring and 
mon i tor i ng n e twork p e rformanc e by calculating the amount of time nodes i n a network 
are active processing and sending frames, as well as the amount of time that the-frames 
spend traversing the network. Graphical user interfa ces are provided to effectively 
present significant measurements and calculations. 
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